Sytems and methods for multi-layer interworking

ABSTRACT

Systems, modules, computer-readable mediums and methods for multi-layer interworking are provided. An identified traffic path is selected from one or more traffic paths. The identified traffic path is selected based on information indicative of traffic path parameter information associated with the identified traffic path relative to traffic path parameter information associated with the other traffic paths. A transport trail is identified from one or more transport trails. Whether the identified transport trail from one or more transport trails is suitable for assignment is determined. The determination is made based on information indicative of the transport trail parameter information associated with the identified transport trail relative to transport trail parameter information associated with the other transport trails. The selected identified traffic path is assigned to the identified transport trail if the identified transport trail is determined to be suitable for assignment.

CROSS-REFERENCE TO RELATED U.S. APPLICATIONS

This application claims priority from U.S. patent application Ser. No.12/039,845, filed on Feb. 29, 2008 and entitled “Systems And Methods ForMulti-Layer Interworking.”

BACKGROUND INFORMATION

Conventional communication systems include numerous layers offunctionality for the provisioning of information, in general, and forthe transportation of information, in particular. Conventional systemsinclude lower-complexity layers that do not differentiate between typesof information or the manner in which the information should betransported. These layers provide a mere pipeline for information.Conventional systems also include higher-complexity layers that processa number of parameters to meet the different service requirements of theinformation being transported. Such processing can result in undesirablesystem complexity and expense. For example, ATM, Frame Relay and MPLSprotocols operate at higher complexity layers and may be overly complexand expensive in certain contexts.

Recommendations for information transportation standards such asInternational Telecommunication-Union-Telecommunication (“ITU-T”) G.800vand G.800v2 are currently being developed. The ITU-T CompositeTransportation Group (“CTG”) is particularly directed to providing newsolutions for transportation standards. The standards, however,currently rely on traditional models of layering and functionality incommunication systems and accordingly suffer from the aforementioneddrawbacks.

BRIEF DESCRIPTION OF THE DRAWINGS

Purposes and scope of exemplary embodiments described below will beapparent from the following detailed description in conjunction with theappended drawings in which like reference characters are used toindicate like elements, and in which:

FIG. 1 is a schematic diagram of a system configured to providemulti-layer interworking in accordance with exemplary embodiments;

FIG. 2 is a schematic diagram of modules of the multi-layer interworkingmodule of the system of FIG. 1 in accordance with exemplary embodiments;

FIG. 3 is a schematic diagram of modules of the multi-layer interworkingmodule of the system of FIG. 1 in accordance with exemplary embodiments;and

FIGS. 4 a, 4 b and 4 c illustrate a flow chart of a method for trafficpath assignment in accordance with exemplary embodiments.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

In exemplary embodiments, systems, modules, computer-readable mediumsand methods for multi-layer interworking are provided. An identifiedtraffic path is selected from one or more traffic paths. The identifiedtraffic path is selected based on information indicative of traffic pathparameter information associated with the identified traffic pathrelative to traffic path parameter information associated with the othertraffic paths. A transport trail is identified from one or moretransport trails. Whether the identified transport trail from one ormore transport trails is suitable for assignment is determined. Thedetermination is based on information indicative of the transport trailparameter information associated with the identified transport trailrelative to transport trail parameter information associated with theother transport trails. The selected identified traffic path is assignedto the identified transport trail if the identified transport trail isdetermined to be suitable for assignment.

In exemplary embodiments, after one or more traffic paths is assigned toone or more transport trails, an assigned traffic path may be re-routedto one or more other transport trails. The assigned traffic path may bere-routed based on a change in transport trail parameter information.The change in the transport trail information may be indicative of achange in a transport trail bandwidth or a change in transport trailreservation threshold.

In exemplary embodiments, after one or more traffic paths are assignedto one or more transport trails, traffic path optimization may beperformed. Traffic path optimization may include evaluating one or moreassigned traffic paths and transport trails and re-assigning any of theassigned traffic paths and transport trails based on traffic pathparameter information and transport trail parameter information.

In other exemplary embodiments, a traffic path assignment process may beperformed as follows. A traffic path may be selected (as described ingreater detail hereinafter), and a determination may be made as towhether a suitable transport trail is available. If a suitable transporttrail is available, a selected traffic path may be assigned to thesuitable transport trail. If a suitable transport trail is notavailable, in exemplary embodiments, no traffic path is assigned. Anotification indicating that no traffic path has been assigned may begenerated. The generated notification may be a failure notification thatmay be transmitted within an exemplary embodiment of a system or outsideof the system.

The description below describes systems, methods and modules, which mayinclude one or more additional modules, some of which are explicitlyshown in the figures and others that are not. As used herein, the term“module” may be understood to refer to computing software, firmware,hardware, circuitry and/or various combinations thereof. It is notedthat the modules are merely exemplary. The modules may be combined,integrated, separated, and/or duplicated to support variousapplications. Also, a function described herein as being performed at aparticular module may be performed at one or more other modules insteadof or in addition to the function performed at the particular moduleshown. Further, the modules may be implemented across multiple devicesand/or other components local or remote to one another. Additionally,the modules may be moved from one device and added to another device,and/or may be included in both devices.

It is further noted that the computer-readable medium described hereinmay be tangibly embodied in one or more physical media, such as, but notlimited to, a compact disc (CD), a digital versatile disc (DVD), afloppy disk, a hard drive, read only memory (ROM), random access memory(RAM), as well as other physical media capable of storing software,and/or combinations thereof.

It should be noted that although the flow charts provided herein show aspecific order of method steps, it is understood that the order of thesesteps may differ from what is depicted. Also two or more steps may beperformed concurrently or with partial concurrence. Such variation willdepend on the software and hardware systems chosen and on designerchoice. It is understood that all such variations are within the scopeof the exemplary embodiments. Likewise, software and web implementationsof the exemplary embodiments could be accomplished with standardprogramming techniques with rule based logic and other logic toaccomplish the various steps.

It is further noted that the figures illustrate various components asseparate entities from one another. The illustration of components asseparate entities from one another is merely exemplary. The componentsmay be combined, integrated, separated and/or duplicated to supportvarious applications. Further, the functions described as beingperformed at various components may be performed at other components,and the various components may be combined and/or separated.

FIG. 1 is a schematic diagram of a system configured to providemulti-layer interworking in accordance with exemplary embodiments. Asused herein, the term “interworking” means the ability for two or moreprotocols, systems, virtual layers or the like to operate with oneanother. As shown, system 100 may include a network 10 that includes oneor more nodes 12, 14, 16, 18, an interworking module 60, one or moretransport trails 70, 80 and one or more traffic paths 80. System 100also includes one or more communication devices configured to transportinformation. As shown, the devices include server 32, desktop computer34, laptop 38 and cell phone 40. The system also includes a network 30and a base station 36 for providing wireless communication to cell phone40. Accordingly, system 100 may provide interworking for informationtransmitted between any of nodes 12, 14, 16, 18, which provideinformation that is controlled by interworking module 20, and any ofdevices 32, 34, 38, 40 shown in system 100.

Network 10 may be any of a number of different types of networks,including, but not limited to, a Wide Area Network (“WAN”), Local AreaNetwork (“LAN”), the Internet, wireless, wired, infrared network, and/orany other network capable of providing functionality according to thattypically associated with layers one, two and/or three of the OpenSystems Interconnection (“OSI”) model which is well known. At least aportion of network 10 complies with the International TelecommunicationUnion-Telecommunication (“ITU-T”) standards recommendation working draftG.800 titled “Unified Functional Architecture of TransportationNetworks,” June 2007, which is incorporated herein by reference in itsentirety. In exemplary embodiments, network 10 is a connection-orientedtransport environment having transport trails 70, 80 established. Inexemplary embodiments, the transport trails 70, 80 may be establishedbefore initiating interworking.

Nodes 12, 14, 16, 18 may be communicatively coupled to one another andconfigured to transmit information to or receive information fromanother node 12, 14, 16, 18 or a node outside of the network. Nodes 12,14, 16, 18 may be any of different types of devices including, but notlimited to, personal computers, mainframe computers, routers, switches,laptops, cellular telephones, PDAs, printers, scanners, or any otherdevice capable of transporting information.

One or more traffic paths 26, 28 may overlay the one or more transporttrails 22, 24. In exemplary embodiments, traffic paths are logical pathsthat transport information. Each of transport trails 22, 24 may betemporary or permanent virtual circuits established between any of nodes12, 14, 16, 18, and may provide information between nodes 12, 14, 16,18.

Each of traffic paths 26, 28 and transport trails 22, 24 may be definedby one or more traffic path parameters and by one or more transporttrail parameters, respectively. The values of the traffic pathparameters and the transport trail parameters may be indicative of theQuality of Service (“QOS”) that may be provided to information beingtransmitted and/or received over the transport trail via the trafficpath. Information indicative of the parameters and the values of theparameters may be passed to layers two and/or three protocols andsystems performing functions characteristic of layers two and/or threeof the OSI model. The parameters and the corresponding values may beprovided to modules operating according to the Asynchronous TransferMode (“ATM”) protocol, the Frame Relay protocol, the Open Shortest PathFirst (“OSPF”) protocol, the Multi-Protocol Label Switching (“MPLS”)technology or any other protocols or functionality that operates toperform one or more functions associated with layers two and/or three,including, but not limited to, transportation of information from afirst node to a second node in the communication system, addressing andinformation routing, admission and rate control and quality of serviceprovisioning. In exemplary embodiments, transportation of informationmay be provided at a desired QOS while reducing cost and complexity ascompared to conventional protocols and technologies such as ATM, FrameRelay and MPLS.

The traffic path parameters may be one or more of a traffic pathbandwidth requirement (“TPBW”), an over-subscription factor (“OF”), aplacement priority (“PP”) or a holding priority (“HP”), each of whichare well-known in the art. In exemplary embodiments, the placementpriority may be equal to or greater than the holding priority to avoidlooping within a preemption process such as the preemption processdescribed below wherein, before a traffic path can be assigned to atransport trail, assignment process is preempted for traffic paths thathave a holding priority less than its corresponding placement priority.

The transport trail parameters may be one or more of a transport trailbandwidth (“TTBW”), a transport trail reservation threshold(“TTReservThresh”) or a transport trail administrative cost(“TTAdminCost”). The transport trail reservation threshold may beindicative of a bandwidth and the bandwidth may be less than a totaltransport trail bandwidth. In exemplary embodiments, the transport trailreservation threshold may be indicated as a percentage of the transporttrail bandwidth or as an absolute number. The transport trailadministrative cost may be a parameter indicative of which transporttrail a user may prefer for transport of information. In exemplaryembodiments, the transport trail administrative cost may be auser-specified parameter. In exemplary embodiments, the transport trailadministrative cost may be a relative term indicative of the transporttrail that the user may prefer for transport of information.Accordingly, the relative term may express the user preference relativeto any of a number of transport trails.

In exemplary embodiments, one or more of the transport trail bandwidth,the transport trail reservation threshold and the transport trailadministrative cost or information indicative thereof may be utilized insystems operating according to features of the OSPF routing protocol. Inexemplary embodiments, OSPF features such as the well-known equal-costrouting, multipath routing and type-of-service request routing mayutilize one or more of the transport trail bandwidth, the transporttrail reservation threshold and the transport trail administrative costor information indicative thereof. The transport trail bandwidth, thetransport trail reservation threshold and the transport trailadministrative cost or information indicative thereof may be used tospecify a particular level of service to be provided to or requested bythe user.

Interworking module 20 may be communicatively coupled to each of nodes12, 14, 16, 18 and configured to provide information to nodes 12, 14,16, 18 via the one or more traffic paths 26, 28 and the one or moretransport trails 22, 24. Interworking module 20 may be configured toprovide interworking to control aspects of the transportation ofinformation between nodes 12, 14, 16, 18. Interworking module 20 may beconfigured to assign one or more traffic paths 26, 28 to transporttrails 22, 24.

Interworking module 20 may provide an optimal quantity and type oftraffic path parameters and transport trail parameters. In oneembodiment, the optimal quantity and type of traffic path parameters andtransport trail parameters is six parameters, which are: traffic pathbandwidth requirement, over-subscription factor, placement priority,holding priority, transport trail bandwidth, transport trail reservationthreshold and transport trail administrative cost.

The traffic path parameters and transport trail parameters may beprovided to a virtual layer that functions in a manner characteristic oflayers two and/or three of the OSI model. The set parameters may be amore limited set than the conventional set of parameters provided tomodules that operate to perform the functions of layers two and/or threeprotocols; however, a minimum amount of information may be provided bymodule 20. Accordingly, module 20 provides interworking betweenconventional virtual layers while reducing the complexity and associatedcost of processing.

FIG. 2 is a schematic diagram of exemplary modules of the interworkingmodule of FIG. 1 in accordance with exemplary embodiments. As shown,interworking module 20′ may make traffic path assignments and providetraffic path re-routing. The interworking module 20′ may include trafficpath assignment module 210 and traffic path re-routing module 220.

The traffic path assignment module 210 may assign one or more of trafficpaths 26, 28 to one or more transport trails 22, 24. In exemplaryembodiments, assigning one or more traffic paths 26, 28 to one or moretransport trails 22, 24 may include the following steps. A traffic pathmay be selected from among one or more traffic paths. Whether a suitabletransport trail is available may be determined. If a suitable transporttrail is available, the selected traffic path may be assigned to thesuitable transport trail.

Traffic path re-routing module 220 may provide re-routing of assignedtraffic paths. In exemplary embodiments, re-routing of assigned trafficpaths may include re-routing based on one or more of a change intransport trail bandwidth, a change in transport trail reservationthreshold or a change in transport trail administrative cost.

In exemplary embodiments, traffic path re-routing module 220 may beconfigured to re-route traffic paths 26, 28 that are assigned totransport trails onto another of one or more transport trails based on achange in the bandwidth of the transport trail. In exemplaryembodiments, traffic path re-routing module 220 may be configured tore-route traffic paths that are assigned to transport trails ontoanother of one or more of transport trails based on a change in thereservation threshold of the trail. In exemplary embodiments, trafficpath re-routing module 220 may be configured re-route traffic paths thatare assigned to transport trails onto another of one or more transporttrails based on a change in the administrative cost of the trail. In anexemplary embodiment, a change in the transport trail administrativecost may not result in re-routing of traffic paths.

FIG. 3 is a schematic diagram of exemplary modules of the interworkingmodule of FIG. 1 in accordance with exemplary embodiments. As shown,interworking module 20″ may provide traffic path selection, transporttrail selection, traffic path assignment preemption, traffic pathassignment enhancement, transport trail bandwidth re-routing, transporttrail reservation re-routing and transport trail administrative costre-routing.

The interworking module 20″ may include the traffic path selectionmodule 310, transport trail selection module 320, preemption module 330,enhancement module 340, transport trail bandwidth re-router module 350,transport trail reservation re-router module 360, and transport trailadministrative cost re-router module 370. The traffic path selectionmodule 310 may select a traffic path among one or more traffic paths.The transport trail selection module 320 may determine whether asuitable transport trail is available. If a suitable transport trail isavailable, module 320 may select the transport trail and assign theselected traffic path to the selected transport trail.

In another exemplary embodiment, the interworking module 20″ may beconfigured to perform traffic path re-routing based on one or more of achange in the transport trail administrative cost, a change in atransport trail bandwidth or a change in a transport trail reservationthreshold.

In the case of changes to the transport trail administrative cost, inexemplary embodiments, no traffic paths are re-routed. In exemplaryembodiments, no traffic paths are re-routed in any cases wherein changesoccur that do not affect the transport trail information capacity. Byway of mere limitation, a change in the administrative cost to maintainthe transport trail may not directly affect the trail'sinformation-carrying capacity and therefore neither an increase nor adecrease in administrative cost prompts re-routing in exemplaryembodiments.

In exemplary embodiments in which there is a change in the transporttrail bandwidth, if the transport trail bandwidth increases or if thetransport trail bandwidth decreases, and the decreased bandwidth (“DB”)is less than or equal to the available bandwidth (“AB”) for thetransport trail, the assigned traffic paths may remain assigned to thecurrent transport trail instead of being re-routed. A transport trailbandwidth may change due to any number of factors. In exemplaryembodiments, a transport trail bandwidth may change based on the numberor type of users in the system or accessing the transport trail oraccording to a setup configuration by which the system or transporttrail operates. The setup may be external to the scope of the systemsand methods disclosed herein but nevertheless cause limitations on thetransport trail bandwidth due to the interaction between the systems andmethods disclosed herein and the network and components thereof that areexternal to the systems and methods.

The decrease in the transport trail bandwidth may be described inabsolute terms as shown above and indicated as “DB”. The decrease intransport trail bandwidth may be described in absolute terms so that itmay be compared with the available bandwidth.

Traffic path preemption (and subsequent traffic path re-routing) mayoccur if the following condition is met:

DB>AB.

Traffic path preemption for re-routing may occur as follows in exemplaryembodiments. A preemptive bandwidth (“PreemptBW”) may be calculatedaccording to the following where the new trail bandwidth after the trailbandwidth changed is represented as NewTBW.

PreemptBW=sum of all ProvTPBW of trafficpaths−NewTBW*(1−TTReservThresh).

A re-routing bandwidth (“ReRouteBW”) may be calculated according to thefollowing:

ReRouteBW=sum of all ProvTPBW of traffic paths with same HP

where ProvTPBW is provisioned traffic path bandwidth and HP is holdingpriority, as defined above.

The re-routing bandwidth may be calculated for all traffic paths withthe same holding priority, starting with all of the traffic paths havingthe lowest holding priority. If the re-routing bandwidth is less thanthe pre-emptive bandwidth, the re-routing bandwidth may be re-calculatedto include the sum of the provisioned traffic path bandwidth of trafficpaths with the next higher holding priority. The process may be repeateduntil the re-routing bandwidth is greater than or equal to thepre-emptive bandwidth. If no calculations yield a re-routing bandwidththat is greater than or equal to the pre-emptive bandwidth, all trafficpaths on the transport trail may be re-routed.

In exemplary embodiments, if the re-routing bandwidth is greater than orequal to the pre-emptive bandwidth, the traffic path re-routing processmay be performed as follows. The traffic paths having the holdingpriority leading to the condition wherein re-routingbandwidth<pre-emptive bandwidth may be assigned to another transporttrail. The new transport trail to which the traffic path may be assignedmay be based on the holding priority and the traffic path bandwidth indescending order.

The module then provides traffic path assignment according to one ormore of the exemplary embodiments described herein, including but notlimited to, those processes performed at blocks 412 to 420 and 424 to444 and the traffic path preemption process, with reference to FIGS. 4a, 4 b and 4 c, which are later discussed in detail. In exemplaryembodiments, the process continues by performing re-routing everytraffic path until the pre-emptive bandwidth is less than or equal tozero.

In exemplary embodiments, if a transport trail becomes available, it maybe treated as a case of a transport trail decrease and all traffic pathson the transport trail may be re-routed.

With reference to FIGS. 2 and 3, one or more of traffic path re-routermodule 220, transport trail bandwidth re-router module 350, transporttrail reservation re-router module 360 or transport trail administrativecost re-router module 370 may be enhanced by implementing traffic pathbundling when performing the steps for traffic path re-routing. Trafficpath bundling may speed the re-routing process and reduce the impact onthe traffic; however, it may also cause sub-optimal traffic pathplacement and routing. In exemplary embodiments, the traffic pathbundling may be provided via bundling on the logical paths thattransport information.

Exemplary embodiments may also include modules for traffic pathre-routing based on a change in a transport trail reservation threshold.In exemplary embodiments in which there is a decrease in the transporttrail reservation threshold in exemplary embodiments, traffic pathre-routing is not performed. In exemplary embodiments in which there isan increase in the transport trail reservation threshold, re-routing maybe performed for the assigned traffic paths if the decreased bandwidthis less than or equal to the available bandwidth.

Traffic path preemption may occur if the decreased bandwidth is greaterthan the available bandwidth. Traffic path preemption may be performedaccording to the following process. Traffic path preemption forre-routing may occur as follows in exemplary embodiments. A preemptivebandwidth may be calculated according to the following where the newtrail bandwidth after the trail bandwidth changed is represented as “Newtransport trail bandwidth”:

PreemptBW=sum of all ProvTPBW of traffic paths−NTBW*(1−TTReservThresh).

A re-routing bandwidth may be calculated according to the following:

ReRouteBW=sum of all ProvTPBW of traffic paths with the same HP.

The re-routing bandwidth may be calculated for all traffic paths withthe same holding priority, starting with all of the traffic paths havingthe lowest holding priority. If the re-routing bandwidth is less thanthe pre-emptive bandwidth, the re-routing bandwidth may be re-calculatedto include the sum of the provisioned traffic path bandwidth of trafficpaths with the next higher holding priority. The process may be repeateduntil the re-routing bandwidth is greater than or equal to thepre-emptive bandwidth. If no calculations yield a re-routing bandwidththat is greater than or equal to the pre-emptive bandwidth, all trafficpaths on the transport trail may be re-routed.

In exemplary embodiments, if the re-routing bandwidth is greater than orequal to the pre-emptive bandwidth, the traffic path re-routing processmay be performed as follows. The traffic paths having the holdingpriority leading to the condition wherein re-routingbandwidth<pre-emptive bandwidth may be assigned to another transporttrail. The new transport trail to which the traffic path may be assignedmay be based on the holding priority and the traffic path bandwidth indescending order.

The module may continue processing with traffic path assignment. Theassignment may be according and with reference to the steps of 412 to420 and of 424 to 446 and FIGS. 4 a, 4 b and 4 c and the traffic pathpreemption process that is part of the traffic path assignment module inexemplary embodiments. In exemplary embodiments, the module may re-routeevery traffic path until the pre-emptive bandwidth is less than or equalto zero.

In exemplary embodiments, a re-routing process may be provided whereinre-routing of traffic paths does not occur upon a change in transporttrail reservation threshold. In this case of a change in a transporttrail reservation threshold but no re-routing of assigned traffic paths,the transport trail may have a negative available bandwidth.

The preemption module 330 may be configured to preempt assignment oftraffic paths to transport trails based on the administrative cost ofthe transport trail. The enhancement module 340 may assign to transporttrails priority ranges indicative of the level of service that can beprovided by the transport trail to enhance the probability that adesired level of service will be met.

The transport trail bandwidth re-router module 350 may be configured tore-route traffic paths 26, 28 that are assigned to transport trails ontoanother of one or more transport trails based on a change in thebandwidth of the transport trail.

The transport trail reservation re-router module 360 may be configuredto re-route traffic paths that are assigned to transport trails ontoanother of one or more of transport trails based on a change in thereservation threshold of the trail.

The transport trail administrative cost re-router module 370 may beconfigured to re-route traffic paths that are assigned to transporttrails onto another of one or more transport trails based on a change inthe administrative cost of the trail.

In an exemplary embodiment, a change in the transport trailadministrative cost may not result in re-routing of traffic paths.Re-routing may be performed in these cases according to periodicoptimization. In an exemplary embodiment of periodic optimization, auser may specify whether the user desires a traffic path to be optimizedbased on the new transport trail administrative cost. In an exemplaryembodiment, the user may specify that a traffic path should not beoptimized notwithstanding a new transport trail administrative cost maybe associated with the transport trail to which the traffic path isassigned. In an exemplary embodiment, the user may specify that atraffic path should be optimized for a new transport trailadministrative cost. In an exemplary embodiment, the user may specifythat a traffic path should be optimized for a new transport trailadministrative cost of a selected amount or when the transport trailadministrative cost changes by a selected amount. The selected amountmay be selected before, during or after system operation and may bedynamically-changeable or static.

The interworking modules 20′, 20″ may also include a traffic pathoptimization module 380. The traffic path optimization module 380 may beconfigured to optimize the assignment of traffic paths on all of theexisting transport trails.

In one exemplary embodiment, the traffic path optimization module 380may be configured to evaluate assigned and unassigned traffic paths andtransport trails and re-assign one or more traffic paths to one or moretransport trails.

In another exemplary embodiment, the traffic path optimization module380 may be configured to provide traffic path assignment enhancement.The traffic path optimization module 380 may provide a priority rangefor each transport trail. The priority ranges may relate to the level ofservice parameters that may be associated with information transported.The priorities may be a function of trail length, as very long transporttrails may not be appropriate to transportation information having alevel of service indicative of the information being delay-sensitive.The priorities may be a function of any aspect of the transport trailthat may affect the level of service that can be provided on thetransport trail. For example, a priority range may be assigned to atransport trail. Traffic paths having a priority range lower than thepriority range of a transport trail may not be assigned to the transporttrail. By way of example, but not limitation, the default priority rangefor a transport trail may be 1-20 and, a traffic path may have apriority range of 1-4. A trail not suitable for such a traffic path maybe assigned a priority range higher than 1-4, such as 5-20. Traffic pathoptimization may be performed at selected intervals. The module mayoperate to perform traffic path optimization periodically.

FIGS. 4 a, 4 b and 4 c illustrate a flow chart of a method for trafficpath assignment in accordance with exemplary embodiments. The exemplaryembodiment is illustrated in FIGS. 4 a, 4 b and 4 c as 400. As shown inFIGS. 4 a, 4 b and 4 c, process 400 is not limited to requirement anyparticular structure for the performance of the process. In particular,the method may be executed or, otherwise performed by one or acombination of various systems as the process steps are not limited toany particular type of structure, whether hardware or software. Withregard to hardware, the processes may be performed by analog or digitalcircuitry such as that found in any number of devices, including, butnot limited to, integrated circuits, an Application-Specific IntegratedCircuit (“ASIC”) chip designed specifically for interworking accordingto the process 400 one or more of the modules shown in FIGS. 1, 2 and 3in embodiments 20, 20′ and 20″ or otherwise. With regard to software,the processes may be performed by computer program products includingprogramming code that may be executed to perform the steps of theprocesses. The computer program products may be part of a module such asthose shown in embodiments of interworking modules 20′ and 20″. Theprocesses may be performed by any computer-readable medium havinginformation stored on the medium for performing the steps of the method.

Referring to method 400, at block 408, placement priorities may bedetermined for all unselected traffic paths. In an exemplary embodiment,the placement priorities for unselected traffic paths may be transmittedfrom a memory (not shown) communicatively coupled to interworking module20 and received by a receiver (not shown) and processed by a processor(not shown) at interworking module 20. The placement priorities aretraffic path parameters and may be associated with informationindicating a high priority placed on being assigned to a transport trailor a low priority placed on such assignment.

In block 410, the one or more traffic paths with the greatest placementpriority is identified. In an exemplary embodiment, a processor atinterworking module 20 may compare the parameters received at itsreceiver. In exemplary embodiments, the parameters may be considered tobe the same if they are equal to or if they are within a determinedrange of one another. The determined range may be decided as a factor ofthe range of the entirety of the parameter values of the unselectedtraffic paths.

In block 412, whether more than one unselected traffic paths has thesame placement priority may be determined. In an exemplary embodiment, aprocessor at interworking module 20 may compare the placement prioritiesreceived at its receiver. In exemplary embodiments, the parameters maybe considered to be the same if they are equal to or if they are withina determined range of one another. The determined range may be decidedas a factor of the range of the entirety of the parameter values of theunselected traffic paths.

In block 414, if not more than one traffic paths have the same placementpriority, the traffic path is selected according to the identifiedtraffic path with the greatest placement priority. In an exemplaryembodiment, a processor at module 20 may compare the parameters receivedat its receiver. In exemplary embodiments, the parameters may beconsidered to be the same if they are equal to or if they are within adetermined range of one another. The determined range may be decided asa factor of the range of the entirety of the parameter values of theunselected traffic paths.

In block 416, processing is performed if it is determined that more thanone unselected traffic path has the same placement priority. In block416, a determination is made as to whether more than one unselectedtraffic paths that have the same placement priority also have the sametraffic path bandwidth. The determination may be made by a processor ofthe interworking module 20. In an exemplary embodiment, making thedetermination may include receiving the traffic path bandwidthrequirements at the processor and comparing the requirements. In anotherexemplary embodiment, making the determination may include accessingsome or all of the traffic path bandwidths at locations remote frominterworking module 20, with reference to FIG. 1, including, but notlimited to, locations on the network 30, a remote server (not shown) orotherwise. In exemplary embodiments, the parameters may be considered tobe the same if they are equal to or if they are within a determinedrange of one another. The determined range may be decided as a factor ofthe range of the entirety of the parameter values of the unselectedtraffic paths.

In block 420, if more than one of the unselected traffic paths that havethe same placement priority do not also have the same traffic pathbandwidth, the traffic path having the greatest traffic path bandwidthrequirement may be selected. Selection may be performed via storage ofidentifying information of a selected traffic path in a memoryassociated with interworking module 20. In exemplary embodiments,selection may be performed via any method allowing access to theinformation for performing the selection.

In block 418, if more than one of the unselected traffic paths that havethe same placement priority also has the same traffic path bandwidth, anunselected traffic path is randomly selected. In an exemplaryembodiment, the unselected traffic path may be randomly selected by arandom number generator associated with interworking module 20 randomlypicking a number and associating the number with an unselected trafficpath.

In block 422, a provisional traffic path bandwidth requirement may becalculated according to the following:

ProvTPBW=TPBW/OverSubFactor

where TPBW is the traffic path bandwidth and OverSubFactor is theover-subscription factor, as defined above. In exemplary embodiments,the calculation may be performed by a processor at the interworkingmodule 20 accessing information indicative of the traffic path bandwidthand over-subscription factor of the selected traffic path. An arithmeticand logic unit (“ALU”) of interworking module 20 may calculate theprovisioned traffic path bandwidth.

FIG. 4 b illustrates the portion of method 400 corresponding toselecting a suitable transport trail. In block 424, the processdetermines the transport trail administrative cost for all transporttrails. In an exemplary embodiment, the administrative costs forunselected traffic paths may be transmitted from memory (not shown)communicatively coupled to interworking module 20, received by areceiver (not shown) and processed by a processor (not shown) atinterworking module 20. The administrative costs are traffic pathparameters and may be associated with information indicating a high (ora low) cost to perform functions for maintaining the integrity of thetransport trail. In exemplary embodiments, determining administrativecosts may include a transmitter of the network module transmittingrequest to an information source able to provide one or more pieces ofinformation that may be used to calculate the administrative costs foreach transport trail. In exemplary embodiments, the administrative costsmay be received at a processor of interworking module 20.

In block 426, a determination is made as to whether more than onetransport trail has the same transport trail administrative cost. Thedetermination may be made by a processor of the interworking module 20.In an exemplary embodiment, making the determination may includeinterworking module 20 requesting from a server in the system of FIG. 1information indicative of the administrative costs of the transporttrails, the server responding by sending the information and theinterworking module 20 comparing the results received at the receiver ofthe module. In exemplary embodiments, the parameters may be consideredto be the same if they are equal to or if they are within a determinedrange of one another. The determined range may be decided as a factor ofthe range of the entirety of the parameter values of the unselectedtraffic paths.

In block 428, if not more than one transport trail has the sameadministrative cost, the transport trail with the lowest administrativecost may be selected and determined to be a suitable transport trail towhich the selected traffic path can be assigned.

In block 430, if more than one transport trail has the sameadministrative cost, the transport trail with the greatest availablebandwidth may be identified. For example, the identification may beperformed in the processor of the module. In exemplary embodiments, theparameters may be considered to be the same if they are equal to or ifthey are within a determined range of one another. The determined rangemay be decided as a factor of the range of the entirety of the parametervalues of the transport trails.

In exemplary embodiments, the available bandwidth may be performed acomparison of the available bandwidth for each transport trail accordingto the following:

AB=TTBW*(1−TTReservThresh)

or

AB=TTBW TTReservThresh

where TTBW is the transport trail bandwidth and TTReservThresh is thetransport trail reservation threshold, as defined above. The availablebandwidth may be calculated by an ALU at interworking module 20.

Available bandwidth can be calculated using the following formula whenthere is a traffic path being carried on the transport trail:

AB=TTBW (1−TTReservThresh)−sum of all ProvTPBW of all traffic pathshaving a higher and equal HP than the PP of the traffic path that isselected for assignment to the transport trail.

In block 432, a determination is made as to whether the identifiedtransport trail has an available bandwidth that is less than provisionedtraffic path bandwidth for the selected traffic path. In an exemplaryembodiment, the determination may be made by comparing the availablebandwidth and the provisioned traffic path bandwidth in a processor ofthe module. In another exemplary embodiment, the determination includescalculating the provisioned traffic path bandwidth and comparing theparameters after identifying a potential suitable transport trail.

In block 434, the identified transport trail is selected if theidentified transport trail has an available bandwidth that is not lessthan the provisioned traffic path bandwidth requirement. In an exemplaryembodiment, the selection may be made by storing information associatedwith the identity of the identified transport trail in a memory atinterworking module 20.

In block 436, a determination is made as to whether the availablebandwidths of each of the transport trails have been compared with theprovisioned traffic path bandwidth requirement. In exemplaryembodiments, the determination may be made by maintaining informationaccessible by interworking module 20 and indicative of the transporttrails for which a comparison of their available bandwidth has beenperformed. The information may be compared against informationindicative of all transport trails of which interworking module 20 isaware. In exemplary embodiments, a memory of interworking module 20 maystore information indicative of the transport trails and the results ofthe comparisons.

In block 438, the transport trail with the next lowest administrativecost is identified if all transport trails have not been considered. Forexample, the identification may be performed in the processor of themodule. In exemplary embodiments, the parameters may be considered to bethe same if they are equal to or if they are within a determined rangeof one another. The determined range may be decided as a factor of therange of the entirety of the parameter values of the transport trails.

In block 442, a determination is made as to whether more than onetransport trail has the same next lowest transport trail administrativecost. The determination may be made by a processor of the interworkingmodule 20. In an exemplary embodiment, making the determination mayinclude interworking module 20 requesting from a server in the system ofFIG. 1 information indicative of the administrative costs of thetransport trails, the server responding by sending the information andthe interworking module 20 comparing the results received at thereceiver of the module. In exemplary embodiments, the parameters may beconsidered to be the same if they are equal to or if they are within adetermined range of one another. The determined range may be decided asa factor of the range of the entirety of the parameter values of theunselected traffic paths.

In block 444, if more than one transport trail has the same lowestadministrative cost, the transport trail with the greatest availablebandwidth may be identified. For example, the identification may beperformed in the processor of the module. In exemplary embodiments, theavailable bandwidth may be performed by a comparison of the availablebandwidth for each transport trail. The available bandwidth may becalculated by an ALU at interworking module 20. In exemplaryembodiments, the parameters may be considered to be the same if they areequal to or if they are within a determined range of one another. Thedetermined range may be decided as a factor of the range of the entiretyof the parameter values of the transport trails.

The process may then perform the steps at block 432 and continue theprocess in accordance with the result of the determination at block 432.Accordingly, the process for determining whether there is a suitabletransport trail may be an iterative process. The process may includesteps to evaluate transport trails based on their one or more transporttrail parameters to determine the suitability of the transport trail fora selected unassigned traffic path.

In block 440, if all transport trails have been considered and notransport trails have been selected at blocks 428 or 434, adetermination may be made that there are no suitable transport trails.

FIG. 4 c illustrates a portion of method 400 of assigning the selectedtraffic path to a suitable transport trail. The process continues fromsteps 440 (or alternately, step 428) illustrated in FIG. 4 b.

In block 448, a determination is made as to whether a suitable transporttrail was identified as available. The determination may be made byreference to a memory of interworking module 20 where informationindicative of such identification may be stored and accessed by theprocessor associated with interworking module 20.

In block 450, if a suitable transport trail was not identified, adetermination may be made to forgo assigning the selected traffic pathto a transport trail. The determination may be performed throughcircuitry such as that of simple logic gates designed to output a signalindicative of whether interworking module 20 should forgo assigning theselected traffic path to the transport trail.

In block 452, a notification indicative of the lack of a suitabletransport trail may be generated. In exemplary embodiments, thenotification is a failure notification. The notification may be receivedby a mechanism configured for monitoring the network 10, interworkingmodule 20 or system 100. In exemplary embodiments, the notification maybe received by an operator disposed to obtain information received atany of the aforementioned locations. In exemplary embodiments, thenotification may be received by a node associated with the selectedtraffic path that was waiting to be assigned to a transport trail.

In block 454, if a suitable transport trail is available, the processmay assign the selected traffic path to the suitable, i.e., selectedtransport trail. The traffic path may be assigned to the selectedtransport trail by interworking module 20 associating the traffic pathon the transport trail. In exemplary embodiments, a port associated witha transport trail may be configured to receive traffic transmitted inassociation with the traffic path.

Process 400 may further include a preemption process. Preemption may beperformed between assignments of selected traffic paths to selectedsuitable transport trails. In these embodiments, preemption may beperformed before any new traffic path can be considered for assignmentto a suitable transport trail. The preemption process may includeevaluating each assigned traffic path to determine whether any of theassigned traffic paths have a holding priority that may be less than itscorresponding placement priority. Preemption may be performed with onany assigned traffic paths that have a holding priority that may be lessthan its corresponding placement priority. During preemption, theassigned traffic paths may be removed from the transport trail andevaluated to determine if they will be assigned to a transport trailagain. The process may be analogous to the process described in steps412 to 420 and in steps 424 to 446, but the processes may be applied tothe preempted traffic paths instead of applying the processes tounselected traffic paths, and may be only performed to evaluatetransport trails on which a transport trail administrative cost is equalto or greater than the current transport trail on which the trafficpaths may be assigned. In an exemplary embodiment, the lower the valueof the transport trail administrative cost, the higher priority thetransport trail may receive in a route selection process in which thetransport trail is included. In an exemplary embodiment, if a firsttransport trail has a transport trail administrative cost of one and asecond transport trail has a transport trail administrative cost of ten,the first transport trail will be selected before the second transporttrail. The first transport trail will be selected before the secondtransport trail until the first transport trail is full, and after thefirst transport trail is full, the second transport trail may then beselected. In exemplary embodiments, selection of transport trails ormethods employed therein may incorporate selection methods of OSPF.

The preemption process may continue until all preempted traffic paths onall impacted transport trails may be assigned. The preemption processcontinues with generation of information indicative of the traffic pathindicating that it may be ready for payload traffic.

After preemption, a second unassigned traffic path may be assignedaccording to the steps of 412 to 420 and 424 to 444 and the stepsoutlined in the preemption process. The steps of 412 to 420 and 424 to444 and the steps outlined in the preemption process may be performed inan iterative manner to assign traffic paths to transport trails.

It will be appreciated that the above described embodiments can beapplied to advantage in numerous real world applications.

For example, exemplary embodiments can be used to solve the well knownparallel trunking congestion problem in MPLS TE enabled backbonenetworks. In today's MPLS backbone, three common methods are used tomanage traffic on parallel trunks between two routers. Two of the threemethods bundle the parallel trunks together into one aggregated logicaltrunk. The first of these two methods uses Layer 1 technology known asLink Aggregation Group (LAG), while the second utilizes MPLS LinkBundling. Both methods utilize logical addressing (VLAN, IP Address,DLCI, etc.) for traffic distribution among multiple link members.Consequently, traffic balance and performance objectives cannot beachieved because those technologies do not recognize LSP bandwidth andor QoS settings. The third known method is to use parallel trunks asthey are (i.e., separate and independent of each other). This causesanother set of problems. For example, where primary LSPs are balancedamong multiple parallel trunks using MPLS TE, bypass tunnel placementcannot be balanced unless bandwidths are assigned to those bypasstunnels. However, doing so wastes valuable backbone resources, andplacing bypass tunnels without assigning bandwidths can result intraffic drop during failure recovery even though there is ample capacityin the backbone. Advantageously, embodiments described herein allowparallel trunks to be bundled together as a single logical trunk.Consequently, CTG systems implemented in accordance with theseembodiments can handle the traffic engineering requirements of MPLSnetworks, while also accommodating link restoration and recovery duringlink member failure.

Exemplary embodiments can also be used to solve the well knownInter-Autonomous System (Inter-AS) Interworking Performance andEfficiency Problem in data networks. In this context, note thatMulti-Protocol Gateway (MPG), MPLS VPN Inter-provider Gateway (MVIC),and Network-to-Network Interface (NNIs or back-to-back UNIs) are themost popular technology choices for inter-carrier connections andinter-AS interworking in today's data networks including MPLS, ATM, andFrame Relay networks. However, each of these choices has significantlimitations. For example, for MPG, diversity and service restoration canbe achieved in three ways (i.e., pre-built primary and secondary paths;reliance upon path crank back; or reliance upon Layer 1 transporttechnology for restoration such as SONET ring and/or Link AggregationGroup), but each of the three techniques has drawbacks (e.g., withpre-built paths, the secondary path captures network resources andincreases network cost, and because the secondary path must be computedafter the primary path is established, the network may not be able tofind a diverse secondary path or the secondary path may be sub-optimal;with path crank back, service restoration can be quite slow; and withreliance on Layer 1 transport technology, network costs aresignificantly increased). These same problems exist for MVIC as well.Moreover, for NNIs or back-to-back UNIs, there usually are no layer 2diversity or service restoration capabilities, and diversity and servicerestoration often depends on a Layer 1 transport layer technology suchas SONET ring and/or LAG. Advantageously, embodiments described hereincan remedy all of these deficiencies. For example, as will beappreciated by those of ordinary skill, a CTG system implemented inaccordance with exemplary embodiments can be used as a supplementaltechnology to solve the diversity and service restoration problem ofMPG. Moreover, coupled with MPG, CTG implemented in accordance withexemplary embodiments can be used as a replacement technology for MVICas will be appreciated. With respect to NNIs and back-to-back UNIs, aCTG system implemented in accordance with exemplary embodiments can bebuilt between Autonomous System Border Router (ASBR) gateways to replacethe above mentioned technologies, as will be appreciated.

Exemplary embodiments can also be used to provide flexible networktrunking solutions for data networks. For example, as will beappreciated, a CTG system implemented in accordance with exemplaryembodiments can bundle different physical interfaces and provide asingle logical interface for a network to use as an aggregated trunk athigher speed. For example, 2 GEs, 2 OC3s, and 1 DS3 can be bundled foran OC48 (2.5 Gbps) equivalent. Moreover, a CTG arrangement constructedin accordance with exemplary embodiments allows a carrier to maximizeuse of existing facilities, especially in regions such as Asia Pacificwhere capacity demand is high, but high speed transports are presentlyrare. Advantageously, CTG systems according to exemplary embodiments canbundle link members with different performance objectives into a singlelogical interface for the network to use as an aggregated trunk athigher speed. For example, it can bundle 2 DS3s where RTD is 150 ms andmultiple DSIs where RTD is 80 ms into an aggregated OC3 equivalent. Thiscan be especially useful in regions (e.g., certain portions of presentday Latin America) where traffic between two countries is heavy, buttransport facilities directly between those countries are rare.

In the preceding specification, various exemplary embodiments have beendescribed with reference to the accompanying drawings. It will, however,be evident that various modifications and changes may be made thereto,and additional embodiments may be implemented, without departing fromthe broader scope of the invention as set forth in the claims thatfollow. The specification and drawings are accordingly to be regarded inan illustrative rather than restrictive sense.

1. A method comprising: assigning a traffic path to a first transporttrail if the first transport trail is determined to be suitable forassignment, wherein the traffic path is associated with traffic pathparameter information; preempting the assignment of the traffic path tothe first transport trail in response to a change in at least one of atransport trail bandwidth parameter, a transport trail reservationthreshold parameter, and a transport trail administrative cost parameterassociated with the first transport trail; selecting a second transporttrail based on associated transport trail parameter information; andassigning the traffic path to the second transport trail if the secondtransport trail is determined to be suitable for assignment.
 2. Themethod of claim 1, wherein the traffic path parameter informationcomprises one or more of a traffic path bandwidth, an over-subscriptionfactor, a placement priority or a holding priority.
 3. The method ofclaim 2, wherein the placement priority associated with the traffic pathis higher than the placement priority associated with any other trafficpaths.
 4. The method of claim 2, further comprising calculating aprovisioned bandwidth requirement for the traffic path.
 5. The method ofclaim 4, wherein calculating the provisioned bandwidth requirementcomprises dividing the traffic path bandwidth by the over-subscriptionfactor.
 6. The method of claim 5, wherein the second transport trail isdetermined to be a suitable transport trail if the transport trailparameter information associated with the second transport trail isindicative of the second transport trail having a bandwidth that isgreater than the provisioned bandwidth requirement.
 7. The method ofclaim 1, wherein the transport trail administrative cost associated withthe second transport trail is lower than the transport trailadministrative cost associated with any other traffic paths.
 8. Themethod of claim 1, wherein the second transport trail is determined tobe suitable if the transport trail parameter information associated withthe second transport trail is indicative of the second transport trailhaving a bandwidth that is greater than a bandwidth required by thetraffic path.
 9. A computer readable medium having an executablecomputer program comprising instructions to perform steps of the methodof claim
 8. 10. A computer readable medium having an executable computerprogram comprising instructions to perform steps of the method ofclaim
 1. 11. A system comprising: a transport trail selection computingapparatus configured to assign a traffic path to a first transport trailif the first transport trail is determined to be suitable forassignment; a preemption computing apparatus configured to preempt theassignment of the traffic path to the first transport trail in responseto a change in transport trail parameter information associated with thefirst transport trail, wherein the transport trail parameter informationcomprises one or more of a transport trail bandwidth, a transport trailreservation threshold, and a transport trail administrative cost; andthe transport trail selection computing apparatus configured to select asecond transport trail and assign the traffic path to the secondtransport trail if the second transport trail is determined to besuitable for assignment; wherein each transport trail comprises at leastone of a temporary virtual circuit and a permanent virtual circuit. 12.A system comprising: a transport trail selection computing apparatusconfigured to select a first transport trail and assign a traffic pathto the first transport trail if the first transport trail is determinedto be suitable for assignment, wherein each transport trail comprises atleast one of a temporary virtual circuit and a permanent virtualcircuit; a preemption computing apparatus configured to preemptassignment of the traffic path to the first transport trail in responseto a change in transport trail parameter information associated with thefirst transport trail, wherein the transport trail parameter informationcomprises one or more of a transport trail bandwidth, a transport trailreservation threshold, and a transport trail administrative cost; and atraffic path re-router computing apparatus configured to re-route thetraffic path from the first transport trail onto one or more othertransport trails based on a change in the transport trail parameterinformation associated with the first transport trail.
 13. A systemcomprising: a computing apparatus configured to identify level ofservice parameter information indicative of information for transport; acomputing apparatus configured to identify communication channelparameter information indicative of one or more resources of thecommunication channel, wherein the communication channel parameterinformation is associated with at least one of a temporary virtualcircuit and a permanent virtual circuit; a computing apparatusconfigured to provide an identified level of service parameterinformation and an identified communication channel parameterinformation to a communication protocol configured to transportinformation a traffic path assignment computing apparatus configured to:assign a traffic path to a first transport trail, wherein assigning thetraffic path to the first transport trail is based on the identifiedlevel of service parameter information and the identified communicationchannel parameter information; a preemption computing apparatusconfigured to: preempt the assignment of the traffic path to the firsttransport trail in response to a change in at least one of theidentified level of service parameter information and the identifiedcommunication channel parameter information, select a second transporttrail; and the traffic path assignment computing apparatus configuredto: assign the traffic path to the second transport trail if the secondtransport trail is determined to be suitable for assignment.
 14. Thesystem of claim 13, wherein the level of service parameter informationcomprises one or more of: a traffic path bandwidth, an over-subscriptionfactor, a placement priority or a holding priority, and wherein thecommunication channel parameter information comprises one or more of: atransport trail bandwidth, a transport trail reservation threshold or atransport trail administrative cost.
 15. The system of claim 13, whereinthe communication protocol is Asynchronous Transfer Mode.
 16. The systemof claim 13, wherein the communication protocol is Frame Relay.
 17. Thesystem of claim 13, wherein the communication protocol is Multi-protocolLabel Switching.
 18. A system comprising: a computing apparatusconfigured to provide a communication protocol to transport information;and an interworking computing apparatus comprising: a computingapparatus configured to identify level of service parameter informationindicative of information for transport; a computing apparatusconfigured to identify communication channel parameter informationindicative of one or more resources of the communication channel; acomputing apparatus configured to provide an identified level of serviceparameter information and an identified communication channel parameterinformation to the communication protocol; a traffic path assignmentcomputing apparatus configured to: assign a traffic path to a firsttransport trail, wherein assigning the traffic path to the firsttransport trail is based on the identified level of service parameterinformation and the identified communication channel parameterinformation; a preemption computing apparatus configured to: preempt theassignment of the traffic path to the first transport trail in responseto a change in at least one of the identified level of service parameterinformation and the identified communication channel parameterinformation, select a second transport trail; and the traffic pathassignment computing apparatus configured to: assign the traffic path tothe second transport trail if the second transport trail is determinedto be suitable for assignment.
 19. The system of claim 18, wherein thelevel of service parameter information comprises one or more of: atraffic path bandwidth, an over-subscription factor, a placementpriority or a holding priority.
 20. The system of claim 18, wherein thecommunication channel parameter information comprises one or more of: atransport trail bandwidth, a transport trail reservation threshold or atransport trail administrative cost.